Review and validate the set of technology principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of application principles, are given in Part III, Architecture Principles .

Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository (see Part V, Architecture Repository), on the basis of the business drivers, stakeholders, and their concerns.

Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture.

Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints. Depending on the degree of sophistication required, these may comprise simple documents and spreadsheets, or more sophisticated modeling tools and techniques.

Determine Overall Modeling Process

For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. Ensure that all stakeholder concerns are covered. If they are not, create new models to address them, or augment existing models (see above).

The process to develop a Technology Architecture incorporates the following steps:

• Define a taxonomy of platform services and logical technology components (including standards)
• Identify relevant locations where technology is deployed
• Carry out a physical inventory of deployed technology and abstract up to fit into the taxonomy
• Look at application and business requirements for technology
• Is the technology in place fit-for-purpose to meet new requirements (i.e., does it meet functional and non-functional requirements)?
  • Refine the taxonomy
  • Product selection (including dependent products)
• Determine configuration of the selected technology
• Determine impact:
  • Sizing and costing
  • Capacity planning
  • Installation/governance/migration impacts

In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the platform service. The areas where the Technology Architecture may be impacted will include the following:

• Performance: The granularity of the service will impact on platform service requirements. Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
• Maintainability: If service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered.
• Location and Latency: Services might interact with each other over remote links and inter-service communication will have in-built latency. Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
• Availability: Service invocation is subject to network and/or service failure. So high communication availability is an important consideration during service decomposition and defining service granularity

Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation.

Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities & Solutions phase.

Identify Required Catalogs of Technology Building Blocks

Catalogs are inventories of the core assets of the business. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., platform service -> logical technology component -> physical technology component).

Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.

The Technology Architecture should create technology catalogs as follows:

• Based on existing technology catalogs and analysis of applications carried out in the Application Architecture phase, collect a list of products in use.
• If the requirements identified in the Application Architecture are not met by existing products, extend the product list by examining products available on the market that provide the functionality and meet the required standards.
• Classify products against the TOGAF TRM if appropriate, extending the model as necessary to fit the classification of technology products in use.
• If technology standards are currently in place, apply these to the technology component catalog to gain a baseline view of compliance with technology standards.

The following catalogs should be considered for development within a Technology Architecture:

• Technology standards
• Technology portfolio

The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, Content Metamodel .

Identify Required Matrices

Matrices show the core relationships between related model entities.

Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.

The following matrix should be considered for development within a Technology Architecture:

• System/Technology matrix

Identify Required Diagrams

Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.

This activity provides a link between platform requirements and hosting requirements, as a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements.

For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine.

If appropriate, extend the Application Architecture diagrams of software distribution to show how applications map onto the technology platform.

For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components. Where available, collect capacity information on the deployed infrastructure.

For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links. Where available, collect capacity information on the communications infrastructure.

The following diagrams should be considered for development within a Technology Architecture:

• Environments and Locations diagram
• Platform Decomposition diagram
• Processing diagram
• Networked Computing/Hardware diagram
• Communications Engineering diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, Content Metamodel .

Identify Types of Requirement to be Collected

Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the data-focused requirements for implementing the Target Architecture.

Within this step, the architecture engagement should identify types of requirement that must be met by the architecture implementation, including:

• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Technology Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

Select Services

The services portfolios are combinations of basic services from the service categories in the TOGAF TRM that do not conflict. The combination of services are again tested to ensure support for the applications. This is a pre-requisite to the later step of defining the architecture fully.

The previously identified requirements can provide more detailed information about:

• Requirements for organization-specific elements or pre-existing decisions (as applicable)
• Pre-existing and unchanging organizational elements (as applicable)
• Inherited external environment constraints

Where requirements demand definition of specialized services that are not identified in TOGAF, consideration should be given to how these might be replaced if standardized services become available in the future.

For each building block, build up a service description portfolio as a set of non-conflicting services. The set of services must be tested to ensure that the functionality provided meets application requirements.

Develop a Baseline Description of the existing Technology Architecture, to support the Target Technology Architecture. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the Target Technology Architecture, and on whether architectural descriptions exist, as described in Approach.

Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository. If nothing exists within the Architecture Repository, define each application in line with the Technology Portfolio catalog (see Part IV, Content Metamodel).

Begin by converting the description of the existing environment into the terms of the organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). This will allow the team developing the architecture to gain experience with the model and to understand its component parts. The team may be able to take advantage of a previous architectural definition, but it is assumed that some adaptation may be required to match the architectural definition techniques described as part of this process. Another important task is to set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture.

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.

Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture. The scope and level of detail to be defined will depend on the relevance of the technology elements to attaining the Target Architecture, and on whether architectural descriptions exist. To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Repository (see Part V, Architecture Repository).

A key process in the creation of a broad architectural model of the target system is the conceptualization of building blocks. Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design. The method of defining building blocks, along with some general guidelines for their use in creating an architectural model, is described in Part IV, Building Blocks and the ADM , and illustrated in detail in Building Blocks Example).

Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.

First, verify the architecture models for internal consistency and accuracy.

Note changes to the viewpoint represented in the selected models from the Architecture Repository, and document.

Test architecture models for completeness against requirements.

Identify gaps between the baseline and target:

• Create gap matrix, as described in Part III, Gap Analysis
• Identify building blocks to be carried over, classifying as either changed or unchanged
• Identify eliminated building blocks
• Identify new building blocks
• Identify gaps and classify as those that should be developed and those that should be procured

Following creation of a Baseline Architecture, Target Architecture, and gap analysis, a Technology Roadmap is required to prioritize activities over the coming phases.

This initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.

Once the Technology Architecture is finalized, it is necessary to understand any wider impacts or implications.

At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:

• Does this Technology Architecture create an impact on any pre-existing architectures?
• Have recent changes been made that impact the Technology Architecture?
• Are there any opportunities to leverage work from this Technology Architecture in other areas of the organization?
• Does this Technology Architecture impact other projects (including those planned as well as those currently in progress)?
• Will this Technology Architecture be impacted by other projects (including those planned as well as those currently in progress)?

• Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
• Fully document each building block
• Conduct final cross-check of overall architecture against business goals; document rationale for building block decisions in the architecture document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used (working practices, roles, business relationships, job descriptions, etc.), and publish via the Architecture Repository
• Finalize all the work products, such as gap analysis

Document the rationale for building block decisions in the Architecture Definition Document.

Prepare the technology sections of the Architecture Definition Document, comprising some or all of:

• Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
• Dependent building blocks with required functionality and named interfaces
• Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
• Map to business/organizational entities and policies

If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.